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OVERVIEW 

AMPHION is a knowledge-based software en- 
gineering (KBSE) system that guides a user in 
developing a diagram representing a formal 
problem specification. It then automatically im- 
plements a solution to this specification as a pro- 
gram consisting of calls to subroutines from a li- 
brary. The diagram provides an intuitive domain- 
oriented notation for creating a specification that 
also facilitates reuse and modification. 

AMPHION'S architecture is domain indepen- 
dent AMPHION is specialized to an application 
domain by developing a declarative domain the- 
ory. Creating a domain theory is an iterative pro- 
cess that currently requires the joint expertise of 
domain experts and experts in automated formal 
methods for software development. 

AMPHION has been applied to JPL’s NAIF do- 
main through a declarative domain theory that 
includes an axiomatization of JPL’s SPICELIB 
subroutine library. Testing with planetary scien- 
tists demonstrates that AMPHlON’s interactive 
specification acquisition paradigm enables users 
to easily develop, modify, and reuse specifica- 
tions after only a short tutorial. AMPHION rou- 
tinely synthesizes programs consisting of dozens 
of SPICELIB subroutine calls from these specifi- 
cations in just a few minutes. 

Qualitative assessments indicate an order of 
magnitude productivity increase using AMPHION 


over manual program development. AMPHION is 
currently undergoing alpha testing in preparation 
for distribution to the NAIF community. Other 
NASA domains are under consideration. Future 
research will address the technology needed for 
domain experts to develop their own AMPHION 
domain theories with only minimal consultation 
from experts in formal methods. 

MOTIVATION 

Within the space science community, subrou- 
tine libraries are a ubiquitous form of software 
reuse. However, space scientists often do not 
make effective use of libraries. Sometimes this 
happens because a subroutine library is devel- 
oped without following good conventional soft- 
ware engineering practices, resulting in inade- 
quate documentation, untrustworthy code, and a 
lack of coherence in the different functions per- 
formed by the individual routines. However, 
even when a subroutine library is developed fol- 
lowing the best conventional software engineer- 
ing practices, users often have neither the time 
nor the inclination to fully familiarize themselves 
with it. The result is that most users lack the ex- 
pertise to properly identify and assemble the rou- 
tines appropriate to their problems. This repre- 
sents an inherent knowledge barrier that lowers 
the utility of even the best-engineered software li- 
braries: the effort to acquire the knowledge to ef- 
fectively use a subroutine library is often per- 
ceived as being more than the effort to develop 
the code from scratch. AMPHION is an effective 
solution to this knowledge barrier. 

The objective of AMPHION is to enable users 
who are familiar with the basic concepts of an 
application domain to program at the level of ab- 
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stract domain-oriented problem specifications, 
rather than at the detailed level of subroutine 
calls. AMPHION breaks through the knowledge 
barrier by enabling use of a subroutine library 
without having to absorb all the documentation 
about a library, especially the plethora of imple- 
mentation details such as the representation con- 
ventions for subroutine parameters. 

NAIF APPLICATION 

The first application domain for AMPHION is 
solar-system kinematics, as implemented in the 
SPICELIB subroutine library developed by the 
Navigation Ancillary Information Facility (NAIF) 
at JPL. SPICELIB is an extremely well-engineered 
library used by planetary scientists to plan and 
analyze the observing geometry for data collected 
during interplanetary missions or by space-based 
telescopes. A domain theory was developed that 
includes an abstract formalization of solar-system 
kinematics suitable for specifying problems, and 
the knowledge needed to implement solutions 
using SPICELIB. To date, Amphion has demon- 
strated the following essential capabilities for 
real-world KBSE: 

1. Users without training in formal methods 
readily develop domain-oriented diagrams cor- 
responding to formal problem specifications 
using Amphion’s specification-acquisition 
tools. 

2. Users can reuse, modify, and maintain previ- 
ously developed specifications, thereby elevat- 
ing the software life cycle from the code level 
to the specification level. 

3. Automatic deductive program synthesis 
achieves acceptable performance, given an ap- 
propriately structured domain theory and mod- 
erate use of theorem-proving tactics. 

Programming at the Specification Level 

To enable users to program at the specification 
level, AMPHION consists of a specification-ac- 
quisition component to guide users in developing 
a formal specification, and a program synthesis 
component that automatically generates a pro- 
gram implementing a solution to the specifica- 
tion. Users enter specifications graphically 
through a menu-guided graphical user interface 
(GUI). Figure 1 is an example of a completed 


specification: it denotes the problem of predicting 
the solar incidence angle at the point on Jupiter 
closest to Galileo at a particular time. (This is the 
sub-spacecraft point). The specification acquisi- 
tion component performs semantic checks on 
completed specification diagrams, and then au- 
tomatically translates them to a logical form used 
by the program synthesis component. 

The output of program synthesis for the NAIF 
application is a FORTRAN-77 program consisting 
of calls to the SPICELIB subroutine library. 
AMPHION generated the SOLAR program in 
Figure 2 from the specification in Figure 1 in 52 
seconds of CPU time on a Sparc 2. In over a 
hundred programs generated by AMPHION for the 
NAIF domain to date, the CPU time has ex- 
ceeded three minutes in only four cases. This is 
an unprecedented level of performance for the 
deductive synthesis approach, developed over 25 
years ago [1,2]. Most of the program synthesis 
component is independent of the target output 
language. It would only take two weeks of work 
to adapt AMPHION for a different output language 
such as C or UNIX shell files. 

AMPHION’s specification language for the 
Naif domain is at the level of abstract geometry. 
This specification language is part of the declara- 
tive domain theory. The vocabulary is basic 
Euclidean geometry (e.g., points, rays, ellip- 
soids, and intersections) augmented with astro- 
nomical terms (e.g., planets, spacecraft, and 
photons; the latter for specifying constraints used 
in calculating light-time correction). The specifi- 
cation language does not include the myriad im- 
plementation details required for correctly calling 
SPICELIB subroutines, such as coordinate 
frames, units, time systems, etc; these details are 
automatically deduced during program synthesis. 
The user only needs to define die abstract prob- 
lem and the desired representation conventions 
for the program inputs and outputs. 

Amphion’s GUI bears a superficial resem- 
blance to data-flow oriented graphical pro- 
gramming environments. For example, Apple's 
HOOKUP application enables users to select icons 
from a palette that represent individual subrou- 
tines, and then connect input and output ports. 
However, these environments only provide an 
alternate notation to conventional programming 
languages. In contrast, AMPHION enables a radi- 
cal separation between the level at which users 
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Figure 1 : Diagram for solar incidence angle developed interactively with AMPHION. 


SUBROUTINE SOLAR { GALILE, ANGLE I 
Input Parameters 
CHARACTER* (*) GALILE 
Output Parameters 
DOUBLE PRECISION ANGLEI 
Function Declarations 
DOUBLE PRECISION VSEP 
Parameter Declarations 
INTEGER JUPITE 
PARAMETER (JUPITE = 599) 

INTEGER GALILl 
PARAMETER {GALILl = -77) 

INTEGER SUN 


PARAMETER (SUN = 

10) 


Variable Declarations 


DOUBLE 

PRECISION 

RADJUP 

( 3 ) 

DOUBLE 

PRECISION 

E 


DOUBLE 

PRECISION 

PVGALI 

( 6 ) 

DOUBLE 

PRECISION 

LTJUGA 


DOUBLE 

PRECISION 

VI ( 3 

) 

DOUBLE 

PRECISION 

X 


DOUBLE 

PRECISION 

PVJUPI 

{ 6 ) 

DOUBLE 

PRECISION 

LTSUJU 


DOUBLE 

PRECISION 

MJUPIT 

{ 3, 3 

DOUBLE 

PRECISION 

V2 ( 3 

) 

DOUBLE 

PRECISION 

XI 


DOUBLE 

PRECISION 

DV2V1 ( 

1 3 ) 

DOUBLE 

PRECISION 

PVSUN ( 

: 6 ) 

DOUBLE 

PRECISION 

XDV2V1 

( 3 ) 

DOUBLE 

PRECISION 

V ( 3 ) 


DOUBLE 

PRECISION 

N { 3 ) 


DOUBLE 

PRECISION 

PN ( 3 

) 

DOUBLE 

PRECISION 

DV2N { 

3 ) 

DOUBLE 

PRECISION 

XDV2N i 

[ 3 ) 


DOUBLE PRECISION DXDV2V ( 3 ) 

DOUBLE PRECISION XDXDV2 ( 3 ) 

C Dummy Variable Declarations 

INTEGER DMY10 

DOUBLE PRECISION DMY20 ( 6 ) 

DOUBLE PRECISION DMY60 ( 6 ) 

DOUBLE PRECISION DMY130 

CALL BODVAR { JUPITE, 'RADII', DMY10, RADJUP ) 
CALL SCS2E { GALILl, GALILE, E ) 

CALL SPKSSB ( GALILl, E, 'J2000', PVGALI ) 

CALL SPKEZ ( JUPITE, E, 'J2000', 'NONE', GALILl, 
DMY20, LTJUGA ) 

CALL VEQU ( PVGALI { 1 ) , VI ) 

X = E - LTJUGA 

CALL SPKSSB ( JUPITE, X, 'J2000', PVJUPI } 

CALL SPKEZ ( SUN, X, 'J2000', 'NONE', JUPITE, 
DMY60, LTSUJU ) 

CALL BODMAT ( JUPITE, X, MJUPIT ) 

CALL VEQU { PVJUPI ( 1 ) , V2 ) 

XI = X - LTSUJU 

CALL VSUB { VI, V2, DV2V1 ) 

CALL SPKSSB { SUN, XI, 'J2000', PVSUN ) 

CALL MXV { MJUPIT, DV2V1 , XDV2V1 ) 

CALL VEQU { PVSUN ( 1 ) , V ) 

CALL NEARPT ( XDV2V1 , RADJUP ( 1 ), 

RADJUP { 2 ), RADJUP { 3 ),N, DMY130) 
CALL SURFNM ( RADJUP { 1 ) , RADJUP ( 2 ) , 

RADJUP ( 3 ). N, PN ) 

CALL VSUB ( N, V2 , DV2N ) 

CALL MTXV ( MJUPIT, DV2N , XDV2N ) 

CALL VSUB ( V, XDV2N, DXDV2V ) 

CALL MXV ( MJUPIT, DXDV2V, XDXDV2 ) 

ANGLEI = VSEP ( XDXDV2 , PN ) 

RETURN 

END 


Figure 2: SOLAR program generated by Amphion from Figure 2. 
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specify problems and the level at which solutions 
are implemented by the program synthesis com- 
ponent. AMPHION’s GUI provides an alternate 
notation to formal specifications written in math- 
ematical logic. The notation of mathematical logic 
can be formidable; that is one reason that specifi- 
cation-based software engineering life cycles 
have not previously been adopted in practice. 

AMPHION's GUI employs an object-oriented 
paradigm for interactively developing problem 
specifications. Conceptually, a user develops a 
problem specification by first defining a configu- 
ration, and then declaring a subset of the objects 
in a configuration to be inputs or outputs of the 
desired program. A configuration is a set of ab- 
stract objects and their relationships. 

A user generates a configuration through the 
actions of adding objects, deleting objects, mov- 
ing the edges between objects that define their 
interrelationships, and by merging objects to- 
gether. Adding and deleting objects are done 
through menus; moving edges and merging ob- 
jects are done by directly manipulating the dia- 
gram. Declaring an object to be an input or output 
of the desired program brings up a menu of the 
possible data-representation conventions: coordi- 
nate systems for locations, time systems for time, 
and units of measurement. These alternative rep- 
resentation conventions are also part of the 
declarative domain theory. 

AMPHION’s specification-acquisition compo- 
nent not only enables specifications to be devel- 
oped from scratch, but it is also especially well 
suited for specification reuse and modification. 
The abstract graphical notation makes it much 
easier to identify the required modifications than 
it is to trace through dependencies in code. 
AMPHION’s editing operations facilitate making 
the changes. Furthermore, there is no possibility 
of introducing bugs in the code, since AMPHION 
synthesizes the code from scratch for the modi- 
fied specification. 

FUTURE DIRECTIONS 

Why the name AMPHION? AMPHION was the 
son of Zeus who used his magic lyre to charm 
the stones lying around Thebes into position to 
form the city’s walls. The AMPHION system’s 
expertise lies in charming subroutines into useful 
programs through Snark, an advanced auto- 


matic theorem prover developed at SRI 
International. A tutorial introduction for this de- 
ductive approach to program synthesis can be 
found in [3], while more details on the use of 
SNARK for synthesizing programs in the NAIF 
domain can be found in [4], One advantage of the 
deductive approach is that a synthesized program 
is guaranteed to be a correct implementation of a 
user's specification, with respect to the domain 
theory. This reduces the software verification 
problem to a one-time verification of the domain 
theory. The declarative nature of the domain the- 
ory simplifies verification. 

Because it uses a generic architecture, de- 
scribed in [5], AMPHION can be applied to other 
domains and subroutine libraries by developing 
the appropriate domain theories. The methodol- 
ogy for developing suitable AMPHION domain 
theories is described in [6], Developing the initial 
NAIF domain theory took three months of collab- 
oration between a NAIF expert and experts in 
automated formal approaches to program syn- 
thesis. Much of the subsequent refinements to the 
domain theory were straightforward and could 
likely be done by domain experts with the appro- 
priate tools. Future research will include develop- 
ing such tools. 
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